In conventional communication systems shown in FIG. 1, a node 10 is required to interface with many neighbors. These are collectively shown in FIG. 1 as “Functional Peer Left” and “Functional Peer Right”. There are strict availability and scalability requirements for the said node on all interfaces. In order to meet availability requirements, the system is implemented using redundant software components, redundant hardware elements and one or more of several possible high availability schemes. Scalability requirements are met through modular design. Software components are mapped to hardware elements which provide an execution environment for these software components. High availability schemes are realized using appropriate check pointing, data replication and failure detection schemes. On failure of a working hardware element or software component, a standby (hot) software component starts functioning in place of the failed software component. It also includes switching of hardware elements.
FIG. 2 shows a communication system 10 comprising plurality of hardware elements 20 through 2x. Software functional components associated with the processing of the interworking with functional peer left comprising plurality of modules 20_500 through 20_5xx and with functional peer right comprising plurality of modules 21_600 through 21_6xx. Functionality of these components is defined by the relevant specification in terms of protocol data units (PDU) or messages received from the functional peer and actions to be taken by the node 10. Such an action is performed by the plurality of software functional components 20_500 through 20_5xx and 21_600 through 21_6xxx and may or may not produce PDU on the same interface or on other interface. To realize this processing, the software functional components 20_500 through 20_5xx and 21_600 through 21_6xx are required to communicate among each other. This type of communication is referred to as inter process communication (IPC). Software function components that communicate with each other using IPC are called IPC end points. This is realized using a network 50 internal to the node. Every hardware element is connected to network 50 through network interface 20_400 through 2x_400 and assigned layer 3 addresses 10.0.0.1 through 10.0.0.x+1. The IPC endpoints may be located on the same hardware element or on different hardware elements. IPC endpoints 20_300 through 2x_300 are responsible for delivering the IPC messages to the destination IPC endpoints. There are also several different timing or design specific considerations for inter process communication.
There are many standard platforms such as cPCI, ATCA, microTCA etc. available off the shelf which can be used to realize node 10. These standard platforms can accommodate one or more hardware elements (such as hardware boards) to realize plurality of hardware element 20 through 2x. These hardware elements have a CPU, memory, the required communication interface, other hardware accelerators and a host operating system such as Linux. A communication interface on the hardware element is assigned one or more IP addresses and used for local-to-remote communication. A loopback interface is also provided for local communication.
IPC routing module maps the destination IPC endpoint to IP address and IPC message is sent through TCP/IP and routed using a kernel IP routing table to the destination IPC endpoint. To communicate with a desired IPC endpoint, the source IPC endpoint is required to select the correct IP address associated with the hardware element where the desired destination IPC endpoint is located. In other words, an IP address is associated with an IPC endpoint. FIG. 3 shows IPC message exchange 1000 from 20_500 to 20_501 located on same hardware element 20. IPC endpoint 20_300 maps 20_501 to the IP address 20_400 and message is routed using IP routing table. IPC endpoint 20_300 receives the message and sends it to 20_501. FIG. 3 also show IPC message exchange 2000 from 20_500 to 21_600 located on hardware elements 20 and 21 respectively. IPC endpoint 20_300 maps 21_600 to the IP address 21_400 and message is routed using IP routing table. IPC endpoint 21_300 receives the message and sends it to 21_600. Hardware element 22 is hot standby to hardware element 21.
The association of an IP address with an IPC endpoint is not fixed and may change because of failure. FIG. 4 shows that on failure of hardware element 21, hardware element 22 becomes active and 21_600 is now associated with different IP address (22_400). This means IPC endpoint 20_300 should send messages for IPC exchange to IP address 22_400.
PDUs from left functional peer and right functional peer are processed in a user data context which may be established through control PDUs exchange or statically configured. There will be many user data contexts exist in the system, one each for every PDUs flow. A scalable system would implement plurality of software functional elements and plurality of hardware elements for handling many user data contexts. Due to this user data context associated with a flow will have many instances. Software functional components are required to communicate with each others to process PDUs associated with user data context. This means a software functional component together with user data context participates in inter process communication and are being referred to as IPC endpoints.
The IPC endpoints may get relocated because of exceeded capacity, failure or change in the Functional peer and will require change in the selected layer 3 address and destination IPC end point by source IPC endpoint for IPC messaging. IPC message exchange between two IPC endpoints is called as IPC message flow.
It can be seen that there is a need for a method and data structures for providing efficient inter process communication where IPC endpoints may be relocated during operation of the system.